Method and apparatus for providing provably secure user input/output

ABSTRACT

A method, non-transitory computer readable medium and apparatus for securing user input and/or output on a mobile endpoint device. For example, the method receives an input on the mobile endpoint device, encrypts and authenticates the input in a trusted domain of the mobile endpoint device executing an application and sends the input that is encrypted and authenticated to an untrusted domain of the mobile endpoint device over a secure channel.

The present disclosure relates generally to mobile device security and,more particularly, to a method and apparatus for providing provablysecure user input/output.

BACKGROUND

Modern smartphones are frequently compromised by malware, potentiallyaccessing sensitive information stored on the device. Evidence has shownthat the traditional approach to securing systems, where attackers findvulnerabilities and then security engineers fix them, is inadequate andprovides an opportunity for attackers to cause significant damage beforethe vulnerability is fixed.

Attackers have become more sophisticated. An attacker can manage tocompletely compromise an operating system of a device by installing akernel-level rootkit. By monitoring user input, an attacker withcomplete control of a device can easily obtain user credentials forsensitive applications such as mobile banking.

SUMMARY

In one embodiment, the present disclosure provides a method for securinguser input and/or output on a mobile endpoint device. For example, themethod receives an input on the mobile endpoint device, encrypts andauthenticates the input in a trusted domain of the mobile endpointdevice executing an application and sends the input that is encryptedand authenticated to an untrusted domain of the mobile endpoint deviceover a secure channel.

In another embodiment, the method receives data in an untrusted domainof the mobile endpoint device that is executing an application, sendsthe data to a trusted domain of the mobile endpoint device executing theapplication over a secure channel, decrypts and authenticates the datain the trusted domain of the application, and displays the data as theuser output on a display of the mobile endpoint device.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure can be readily understood by considering thefollowing detailed description in conjunction with the accompanyingdrawings, in which:

FIG. 1 illustrates one example of a communications network of thepresent disclosure;

FIG. 2 illustrates an example flowchart of one embodiment of a methodfor installing an application on a mobile endpoint device;

FIG. 3 illustrates an example flowchart of one embodiment of a methodfor securing user input and output on a mobile endpoint device; and

FIG. 4 illustrates a high-level block diagram of a general-purposecomputer suitable for use in performing the functions described herein.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures.

DETAILED DESCRIPTION

The present disclosure broadly discloses a method, non-transitorycomputer readable medium and apparatus for securing user input andoutput on a mobile endpoint device. Attackers have become moresophisticated. An attacker can manage to completely compromise anoperating system of a device by installing a kernel-level rootkit. Bymonitoring user input, an attacker with complete control of a device caneasily obtain user credentials for sensitive applications such as mobilebanking. One embodiment of the present disclosure attempts to secure auser's input and output on a mobile endpoint device by separating themobile endpoint device that executes an application into a trusteddomain containing a user interface portion of the application and anuntrusted domain containing a logic portion of the application.

FIG. 1 is a block diagram depicting one example of a communicationsnetwork 100. The communications network 100 may be any type ofcommunications network, such as for example, a traditional circuitswitched network (e.g., a public switched telephone network (PSTN)) or apacket network such as an Internet Protocol (IP) network (e.g., an IPMultimedia Subsystem (IMS) network, an asynchronous transfer mode (ATM)network, a wireless network, a cellular network (e.g., 2G, 3G, and thelike), a long term evolution (LTE) network, and the like) related to thecurrent disclosure. It should be noted that an IP network is broadlydefined as a network that uses Internet Protocol to exchange datapackets. Additional exemplary IP networks include Voice over IP (VoIP)networks, Service over IP (SoIP) networks, and the like.

In one embodiment, the network 100 may comprise a core network 102. Thecore network 102 may be in communication with one or more accessnetworks 120 and 122. The access networks 120 and 122 may include awireless access network (e.g., a WiFi network and the like), a cellularaccess network, a PSTN access network, a cable access network, a wiredaccess network and the like. In one embodiment, the access networks 120and 122 may all be different types of access networks, may all be thesame type of access network, or some access networks may be the sametype of access network and other may be different types of accessnetworks. The core network 102 and the access networks 120 and 122 maybe operated by different service providers, the same service provider ora combination thereof.

In one embodiment, the core network 102 may include an applicationserver (AS) 104 and a database (DB) 106. Although only a single AS 104and a single DB 106 are illustrated, it should be noted that any numberof application servers 104 or databases 106 may be deployed.

In one embodiment, the access network 120 may be in communication withone or more mobile endpoint devices (also referred to as “endpointdevices”) 108 and 110. In one embodiment, the endpoint device 108 may bea mobile endpoint device such as a cellular telephone, a smart phone, atablet computer, a laptop computer, a netbook, a portable media device(e.g., an iPod® touch or MP3 player), and the like. Although only twomobile endpoint devices 108 and 110 are illustrated, it should be notedthat any number of mobile endpoint devices may be deployed.

In one embodiment, the access network 122 may be in communication withone or more third party servers 112 and 114. In one embodiment, thethird party servers 112 and 114 may be servers of third party serviceproviders that may send and receive sensitive information to and fromthe mobile endpoint devices 108 and 110. For example, the third partyservice providers may be banks, financial institutions, onlineretailers, and the like. Although only two third party servers 112 and114 are illustrated, it should be noted that any number of third partyservers may be deployed.

It should be noted that the network 100 has been simplified. Forexample, the network 100 may include other network elements (not shown)such as border elements, routers, switches, policy servers, securitydevices, gateways, a content distribution network (CDN) and the like.

FIG. 2 illustrates an example flow chart of a method for installing anapplication on a mobile endpoint device, for example the mobile endpointdevice 108. Namely, FIG. 2 illustrates one example of the present methodrelative to different domains to provide secure installation of theapplication. In one embodiment, one or more operations of the method ofFIG. 2 may be performed by the endpoint device 108 (e.g., a processor ofthe mobile endpoint device) or a general purpose computing device asillustrated in FIG. 4 and discussed below.

In one embodiment, each application that is installed on the mobileendpoint device 108 may be split into different domains; namely atrusted domain 202 and an untrusted domain 204. The mobile endpointdevice 108 may also include a controller domain 206. In one embodiment,the trusted domain 202 may also be referred to as a user interface (UI)domain. In one embodiment, the untrusted domain 204 may also be referredto as a user domain or a logical domain.

In one embodiment, by separating each application into these differentdomains, the input and outputs received by the UI in the trusted domain202 is protected from potential attackers with the control of theuntrusted domain 204. To guarantee integrity of the system, the trusteddomain 202 has no communication with any external sources except througha formally verified secure channel.

In one embodiment, the trusted domain 202 includes a secure home screen208 and a secure installer 210. In one embodiment, the untrusted domain204 includes a storage medium 212 (e.g., memory and the like) thatincludes one or more applications 214. In one embodiment, the controllerdomain 206 includes a secure storage medium 216 (e.g., memory and thelike) that includes one or more secured application resources 218.

In one embodiment, execution of the application in different domainsdoes not require application programmers to change the way that theapplications are conventionally developed. The application may be parsedto separate the application into the trusted domain 202 containing theUI portions of the application and the untrusted domain 204 containingthe logic portions of the application. For example, a library of wrapperfunctions can be used to translate normal UI related calls within theuntrusted domain 204 to their secure equivalent. Application layoutfiles and resources can be automatically extracted from an applicationand used to display the UI within the trusted domain 202.

In one embodiment, any virtualization platform (e.g., open source ornon-open source) may be used to isolate the application into thedifferent domains. One example of an open source virtualization platformthat may be used is Xen® hypervisor. In one embodiment, the trusteddomain 202 and the untrusted domain 204 may be considered as twoseparate Xen virtual machines each running a full fledge version of theoperating system (e.g., Android®) of the mobile endpoint device. Thecontroller domain 206 may operate to control and manage both the trusteddomain 202 and the untrusted domain 204.

In one embodiment, at step 1, the method receives an install action froma user. For example, the user may initiate the mobile endpoint device108 to install a new application. The new application may be located onan external storage device, for example, such as secure digital (SD)memory card or an app store on a third party server. A hardwareisolation layer, such as ARM TrustZone, can also be used to securelyisolate each domain.

At step 2, the secure home screen 208 may initialize a secure installer210. For example, a controller physical home button may be pressed toget to the secure home screen 208 and terminate operation of any otherapplications that are executing in the background to prepare forinstallation of the new application.

At step 3 a, the secure installer may request a package list of theapplication from the controller domain 206. At step 3 b, the controllerdomain 206 may request the package list from the storage medium 212 inthe untrusted domain 204. At step 3 c, the storage medium 212 in theuntrusted domain 204 may provide the package list for the applicationback to the controller domain 206. At step 3 d, the controller domain206 may provide the package list for the application to the secureinstaller 210 in the trusted domain 204.

At step 4, the user may select an application from a list of apps. Thesecure installer 210 may receive the application that is selected fromthe user.

At step 5 a, the secure installer 210 in the trusted domain 202 mayrequest the application resources for the selected application from thecontroller domain 206. In one embodiment, specifically in an Android®implementation, the application resources may include an applicationpackage file (APK) file associated with the application and public keysassociated with the application. In one embodiment, the APK file and thepublic key may be used during the launch and execution of theapplication, as discussed in further detail below in FIG. 3.

At step 5 b, the controller domain 206 may request the applicationresources for the selected application from the storage medium 212 inthe untrusted domain 204. At step 5 c, the storage medium 212 in theuntrusted domain 204 may send the application resources for the selectedapplication to the controller domain 206. In one embodiment, a copy ofthe application resources may be stored in the secure storage medium 216of the controller domain 206 as illustrated by the secured applicationresources 218. At this point, the secure installer 210 may install therequested application using the secured application resources 218 fromthe controller domain 206 and the method ends.

It should be noted that the untrusted domain 204 does not participate inthe installation process. Rather, the controller domain 206 directlyaccesses a memory containing the installation instructions (e.g., asecure digital (SD) card) without relying on the integrity of theuntrusted domain 204. Thus, assuming that the user is attempting toinstall a secure application (i.e., the user is not attempting to hacktheir own mobile endpoint device 108), the installation of theapplication on the mobile endpoint device 108 is likely to be secure.

FIG. 3 illustrates a flowchart of a method for one embodiment ofsecuring user input and output on a mobile endpoint device. In oneembodiment, one or more operations of the method 300 may be performed bythe endpoint device 108 (e.g., a processor of the mobile endpointdevice) or a general purpose computing device as illustrated in FIG. 4and discussed below.

FIG. 3 illustrates the division of the mobile endpoint device 108 intothe different domains described above in FIG. 2. For example, the mobileendpoint device 108 may include the trusted domain 202, the controllerdomain 206 and the untrusted domain 204.

Once the application is installed onto the mobile endpoint device 108,the application may attempt to communicate with a third party server112, for example a server of a banking web site. Sensitive information,for example bank account balances, bank account numbers, passwords,usernames, and the like, may be exchanged between the mobile endpointdevice 108 and the third party server 112 during communications. Asdiscussed above, if a hacker obtains complete control of the mobileendpoint device 108, the hacker may easily monitor the input at the userinterface of the mobile endpoint device 108 to capture sensitive inputsand outputs exchanged between the mobile endpoint device 108 and thethird party server 112. The method described and illustrated in FIG. 3provides one method of ensuring secure user input and output on themobile endpoint device 108.

The method begins at step 1 where a user presses a “home” button orinitiates a reset action on the mobile endpoint device 108. At step 2 a,the controller domain 206 resets the UI environment 304 located in thetrusted domain 202. For example, any applications that may be running inthe background in the trusted domain 202 of the mobile endpoint device108 may be terminated. In one embodiment, this ensures that if anotherapplication on the mobile endpoint device 108 is hacked that the hackedapplication cannot obtain control of or access to any other securedapplication. At step 2 b, the controller domain 206 initializes thesecure home screen 208 of UI environment 304 in the trusted domain 202.

At step 3, the user selects an application. At step 4 a, the secure homescreen 208 sends a user application initialization request to thecontroller domain 206. The controller domain 206 may then send theapplication UI initialization information to the application UIcomponent 306 in the UI environment 304 in the trusted domain 202 atstep 4 b. At step 4 c, the controller domain 206 initializes theapplication logic component 308 such that it may be ready tocommunicate.

At step 5, the controller domain 206 may send the secured applicationresources 218 to the application UI component 306 to run the UI of theselected application. In one embodiment, the application UI component306 may be executed by an application that copies the UI of theapplication in the trusted domain 202. For example, one type of suchapplication that can be used is the Mimic application.

In one embodiment, all application code and logic besides the UI of theapplication may execute in the untrusted domain 204 within the normalinstance of the application. For example, the secured applicationresources 218 may include a package name and a layout of the applicationthe Mimic application will be mimicking. The Mimic application may thenexchange messages, through a formally verified secure channel, with thelogic portion of the application in the untrusted domain 204 whenever acommand is received from a user.

In one embodiment, the secured application resources 218 may include thepublic key and the application layout stored from the method describedin FIG. 2. In one embodiment, session keys may include a messageauthentication code (MAC) key and an encryption key. The MAC key may beused to generate and verify MACs to authenticate that data being sentbetween the mobile endpoint device 108 and the third party server 112are from the correct source. The encryption key may be used to encryptand decrypt encrypted data that is sent between the mobile endpointdevice 108 and the third party server 112.

At step 6, the application UI component 306 may send a graphical userinterface (GUI) prompt to the user. For example, the GUI may prompt theuser to enter a username and password for accessing the sensitiveinformation stored on the third party server 112. At step 7, the userprovides an input to the application UI component 306, e.g., the user'susername and password.

At step 8, the application UI component 306 may encrypt and authenticate(e.g., via the MAC) the input received from the user at step 7 andtransmit the input over a secured communication channel 302 to theapplication logic component in the untrusted domain 204. In oneembodiment, the secure communication channel 302 is created using asingle shared memory page.

In one embodiment, the isolation layer may provide built-in support forinter domain communication. This can be used to establish a securecommunication channel 302 between the UI domain and the untrusted domain204. In a Xen specific implementation, a grant table can be used toobtain a shared 4 kilobyte (KB) page of memory. When the UI component ofan application first starts, it can initiate the creation of the securechannel. In the case of Xen, the shared memory page must be initializedthrough Xen's grant table application programming interface (API). Xenidentifies this shared memory page using a grant reference number, whichmust be passed to the untrusted domain 204 in order to map this sharedpage for communication.

In one embodiment, the grant reference number is passed to the untrusteddomain 204 using a normal user datagram protocol (UDP) socket. Noresponse is received from the untrusted domain 204 in order to maintainsecurity of the system. Once the untrusted domain 204 receives the grantreference number, using the same API, it maps the shared memory pageinto its own address space. At this point the secure communicationchannel 302 is established and all information passing between theuntrusted domain 204 and the trusted domain 202 occurs over thischannel.

In one embodiment, a formally verified library, written in C forexample, may be used to interact with the shared memory page for securecommunications between the trusted domain 202 and the untrusted domain204. The library may contain functions used to read and write to theshared channel both from the trusted domain 202 and the untrusted domain204. The write function may write some specified data to the sharedmemory page and set various flags to notify the opposite side that thereis data to read. After the data is read, the flags and the data may becleared and the channel can be used again. In this way, only one messagecan be sent between each side at a time and a message must be readbefore another message can be sent. In one embodiment, a spinlockmechanism may be used on the shared memory page to ensure that everyread and write is a truly atomic operation.

Due to control data, only a fixed number of bytes can fit on a sharedpage. In other words, each message that is sent over the secure channelmust fit within a fixed amount of memory. In one embodiment, the messagemust fit within approximately 3096 bytes of memory. To ensure that noapplication can write past this boundary, the bounds are checked forevery write. In addition, reads are placed into a properly sized buffer.

In one embodiment, the input may be encrypted and signed using theencryption key and the signature key for the session before beingtransmitted over the secure communication channel 302. In oneembodiment, encryption may be done via “piping” the secure user inputdirectly from the UI environment 304 in the trusted domain 202 into thesecured communication channel 302. For example, the application mayissue a command of the form:write_to_tunnel(“Password=”+get_secure_field_value(PASSWORD))

In the example above, PASSWORD is a unique identifier of the passwordfield in the UI environment 304. The function “get_secure_field_value”never returns the field value to the caller. Instead, it returns ahandle that the function “write_to_tunnel,” executed in the trusteddomain 202, can use to retrieve the value of the user entered password.Consequently, the result of the above call is that the string“Password=pass” is written to the secure communication channel 302,where “pass” is the user entered password. Since the securecommunication channel 302 end point is in the trusted domain 202, thepassword never passes unencrypted through the untrusted domain 204.

At step 9, the encrypted and signed user input is sent from theapplication logic component 308 in the untrusted domain 204 to the thirdparty server 112. The third party server 112 may then decrypt the userinput using a session key. In one embodiment the session key may includea block cipher key and a message authentication code (MAC) key.

At step 10, the third party server 112 may then send a response back tothe mobile endpoint device 108, for example requested bank accountinformation. In one embodiment, the encrypted and signed response isreceived at the mobile endpoint device by the application logiccomponent 308 in the untrusted domain 204.

The third party server 112 may encrypt and sign the response beforetransmitting the response to the mobile endpoint device 108. In oneembodiment, the encrypted and unencrypted parts of the response from thethird party server 112 may be separated by a delimiter. Each applicationmay define a delimiter “DELIM,” which may be specified as part of theinstallation procedure described in FIG. 2 above and signed by thepublic key of the application. Any information sent from the third partyserver 112 may be split according to the specified delimiter and contentbetween every two delimiters may be considered to be sensitive. Forexample, if the delimiter is “#” and the response is bank accountinformation such as a password and account balance, then in thetransmission:

-   -   Login: Alice; Password: #12345#; Account balance: #$100#,        the strings “12345” and “$100” would be identified as being        sensitive, while the rest of the data may be considered as being        non-sensitive. The trusted domain 202 may then process the        incoming data from the third party server 112 by storing each        sensitive string locally and replacing it with a handle before        forwarding it to the untrusted domain 204. In the above example,        the application running in the untrusted domain 204 would        receive the following text:    -   Login: Alice; Password: [handle 1]; Account balance: [handle 2]        The application may then use handle 1 and handle 2 in future        calls to the trusted domain 202.

At step 11, the application logic component 308 may send the encryptedand signed response over the secure communication channel 302 to theapplication UI component 306 in the trusted domain 202. The applicationUI component 306 may then decrypt the encrypted and signed responseusing the appropriate handles discussed above and appropriate sessionkeys. At step 12, the results may be displayed to the user in the secureUI environment 304 in the trusted domain 202.

It should be noted that in the method described above in reference toFIG. 3 that the untrusted domain 204 and the trusted domain 202 onlycommunicate over the secured communication channel 302. In addition, nodata from the trusted domain 202 goes to the untrusted domain 204without encryption. As a result, a hacker who may have gained controlover the mobile endpoint device 108 may still not be able to obtainsensitive information by monitoring the user's inputs and outputs. Thelogical component of an application is separated from the user interfacecomponents of the application and all user inputs and outputs areencrypted before being passed to the logical component of theapplication. As a result, the embodiments of the present disclosuresecure a user's inputs and outputs on a mobile endpoint device.

It should be noted that although not explicitly specified, one or moresteps of the methods described above may include a storing, displayingand/or outputting step as required for a particular application. Inother words, any data, records, fields, and/or intermediate resultsdiscussed in the methods can be stored, displayed, and/or outputted toanother device as required for a particular application. Furthermore,operations, steps or blocks in FIGS. 2 and 3 that recite a determiningoperation, or involve a decision, do not necessarily require that bothbranches of the determining operation be practiced. In other words, oneof the branches of the determining operation can be deemed as anoptional step. Furthermore, operations, steps or blocks of the abovedescribed methods can be combined, separated, and/or performed in adifferent order from that described above, without departing from theexample embodiments of the present disclosure.

FIG. 4 depicts a high-level block diagram of a general-purpose computersuitable for use in performing the functions described herein. Asdepicted in FIG. 4, the system 400 comprises a hardware processorelement 402 (e.g., a CPU), a memory 404, e.g., random access memory(RAM) and/or read only memory (ROM), a module 405 for securing userinput and output on a mobile endpoint device, and various input/outputdevices 406, e.g., near field communications capability, anaccelerometer, a gyro, a camera, a light sensor, a microphone, acompass, pressure sensor, a temperature sensor, storage devices,including but not limited to, a tape drive, a floppy drive, a hard diskdrive or a compact disk drive, a receiver, a transmitter, a speaker, adisplay, a speech synthesizer, an output port, and a user input device(such as a keyboard, a keypad, a mouse, and the like).

It should be noted that the present disclosure can be implemented insoftware and/or in a combination of software and hardware, e.g., usingapplication specific integrated circuits (ASIC), a general purposecomputer or any other hardware equivalents, e.g., computer readableinstructions pertaining to the method(s) discussed above can be used toconfigure a hardware processor to perform the operations or steps of theabove disclosed method. In one embodiment, the present module or process405 for securing user input and output on a mobile endpoint device canbe implemented as computer-executable instructions (e.g., a softwareprogram comprising computer-executable instructions) and loaded intomemory 404 and executed by hardware processor 402 to implement thefunctions as discussed above. As such, the present method 405 forproviding security on a mobile endpoint device as discussed above in thevarious methods (including associated data structures) of the presentdisclosure can be stored on a non-transitory (e.g., tangible orphysical) computer readable storage medium, e.g., RAM memory, magneticor optical drive or diskette and the like.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. Thus, the breadth and scope of a preferred embodiment shouldnot be limited by any of the above-described exemplary embodiments, butshould be defined only in accordance with the following claims and theirequivalents.

What is claimed is:
 1. A method for securing a user input on a mobileendpoint device having at least one processor, comprising: receiving, bythe at least one processor, the user input on the mobile endpointdevice; encrypting and authenticating, by the at least one processor,the user input in a trusted domain of the mobile endpoint deviceexecuting an application; and sending, by the at least one processor,the user input that is encrypted and authenticated to an untrusteddomain of the mobile endpoint device over a secure channel, wherein thetrusted domain comprises a user interface portion of the application forsecuring the user input, wherein the untrusted domain comprises alogical portion of the application.
 2. The method of claim 1, whereinthe encrypting comprises using a session key that is generated each timethe application is started.
 3. The method of claim 2, wherein thesession key comprises a message authentication code component and anencryption component.
 4. The method of claim 1, wherein the user inputthat is sent over the secure channel fits within a fixed amount ofmemory.
 5. The method of claim 1, wherein the secure channel relies onan inter domain communication mechanism supplied by an isolation layer.6. A non-transitory computer-readable medium storing a plurality ofinstructions which, when executed by a processor of a mobile endpointdevice, cause the processor to perform operations for securing a userinput on the mobile endpoint device, the operations comprising:receiving the user input on the mobile endpoint device; encrypting andauthenticating the user input in a trusted domain of the mobile endpointdevice executing an application; and sending the user input that isencrypted and authenticated to an untrusted domain of the mobileendpoint device over a secure channel, wherein the trusted domaincomprises a user interface portion of the application for securing theuser input, wherein the untrusted domain comprises a logical portion ofthe application.
 7. The non-transitory computer-readable medium of claim6, wherein the encrypting comprises using a session key that isgenerated each time the application is started.
 8. The non-transitorycomputer-readable medium of claim 7, wherein the session key comprises amessage authentication code component and an encryption component. 9.The non-transitory computer-readable medium of claim 6, wherein the userinput that is sent over the secure channel fits within a fixed amount ofmemory.
 10. The non-transitory computer-readable medium of claim 6,wherein the shared channel comprises a single shared memory page.
 11. Amethod for securing a user output on a mobile endpoint device having atleast one processor, comprising: receiving, by the at least oneprocessor, data in an untrusted domain of the mobile endpoint devicethat is executing an application; sending, by the at least oneprocessor, the data to a trusted domain of the mobile endpoint deviceexecuting the application over a secure channel, wherein the trusteddomain comprises a user interface portion of the application forsecuring the user output, wherein the untrusted domain comprises alogical portion of the application; decrypting and authenticating, bythe at least one processor, the data in the trusted domain of the mobileendpoint device executing the application; and displaying, by the atleast one processor, the data as the user output on a display of themobile endpoint device.
 12. The method of claim 11, wherein thedecrypting comprises using a delimiter to identify a portion of the datathat is sensitive.
 13. The method of claim 12, wherein the decryptingcomprises replacing the portion of the data that is identified as beingsensitive with a handle.
 14. The method of claim 11, wherein thedecrypting comprises using a session key.
 15. The method of claim 14,wherein the session key comprises a message authentication codecomponent and an encryption component.
 16. The method of claim 11,wherein the data that is sent over the secure channel fits within afixed amount of memory.